---
title: Gas Fees
description: A Sui transaction must pay for both the computational cost of execution and the long-term cost of storing the objects a transaction creates or mutates.
keywords: [ sui gas, gas fees, sui gas tokens, pay for gas, how to pay gas, gas fee, sui gas fee, how much is gas, gas prices, price of gas ]
---

A Sui transaction must pay for both the computational cost of execution and the long-term cost of storing the objects a transaction creates or mutates. 

The Sui gas pricing mechanism achieves three outcomes: 

1. Deliver predictable transaction fees.

1. Incentivize validators to optimize their transaction processing operations.

1. Prevent denial of service attacks.

This pricing mechanism gives you the best user experience without needing to forecast the current market price of gas fees. Because validators agree on a network-wide reference price at the start of each epoch, you can use the reference price as a credible anchor when submitting transactions. Moreover, the price setting mechanism rewards good validator behavior, thus aligning incentives between SUI token holders, validators, and users.

## Gas fee structure

Gas fees for any transaction equal:

```
total_gas_fees = computation_units × reference_gas_price + storage_units × storage_price
```

A unique feature of the Sui gas price mechanism is that users pay separate fees for transaction execution and for storing the data associated with each transaction. The gas fees associated with an arbitrary transaction τ equal:

$$
GasFees[\tau] = ComputationUnits[\tau] \times ComputationPrice[\tau] + StorageUnits[\tau] \times StoragePrice
$$

The gas functions $ComputationUnits[\tau]$ and $StorageUnits[\tau]$ measure the amount of computation and storage resources, respectively, required to process and store the data associated with τ. The gas prices $ComputationPrice[\tau]$ and $StoragePrice$ translate the cost of computation and storage, respectively, into SUI units. The decoupling between gas units and gas prices is useful because SUI market price fluctuates over time in accordance with supply and demand.

## Computation units {#computation}

Different Sui transactions require varying amounts of computational time for processing and execution. Sui translates these varying operational loads into transaction fees by measuring each transaction in terms of computation units. In general, more complex transactions require more computation units.

Sui's computation gas schedule is built coarsely with a bucketing approach. Two relatively similar transactions translate into the exact same amount of computation units if they are in the same bucket, whereas two relatively different transactions translate into different amounts of computation units if they fall in separate buckets. The smallest bucket maps into 1,000 computation units, meaning that all transactions that fall into the smallest bucket cost 1,000 computation units. The largest bucket maps into 5,000,000 computation units; if a transaction requires more computation units, it aborts.

Using coarse bucketing accomplishes two important goals:

- Frees you from optimizing your smart contracts to deliver marginal gains in gas costs through gas golfing. Instead, you can focus on step-function improvements in your products and services.

- Gives you the freedom to adjust per-instruction gas costs and experiment with new gas metering schemes without creating significant development disruption. This can happen frequently, so it is important that you do not rely on per-instruction gas costs remaining stable over time.

| Bucket lower threshold | Bucket upper threshold | Computation units      |
| ---------------------- | ---------------------- | ---------------------- |
| 0                      | 1,000                  | 1,000                  |
| 1,001                  | 5,000                  | 5,000                  |
| 5,001                  | 10,000                 | 10,000                 |
| 10,001                 | 20,000                 | 20,000                 |
| 20,001                 | 50,000                 | 50,000                 |
| 50,001                 | 200,000                | 200,000                |
| 200,001                | 1,000,000              | 1,000,000              |
| 1,000,001              | 5,000,000              | 5,000,000              |
| 5,000,001              | Infinity               | transaction aborts     |

## Storage units {#storage}

Similarly, Sui transactions vary depending on the amount of new data written into on-chain storage. The variable storage units capture these differences by mapping the amount of bytes held in storage into storage units. The current Sui schedule is linear and maps each byte into 100 storage units. For example, a transaction that stores 25 bytes costs 2,500 storage units, while a transaction that stores 75 bytes costs 7,500 units.

In the Sui [storage fund](/concepts/tokenomics.mdx#storage-fund) model, users pay up front for the cost of storing data in perpetuity but can also get a partial rebate on previously stored data if that data is deleted. Hence, the amount of storage fees that you pay can be split into a rebateable and non-rebateable amount. Initially, the rebateable amount equals 99% of the storage fees, while the non-rebateable amount equals the remaining 1%.

### Storage rebates 

Sui storage mechanics provide storage fee rebates whenever a transaction deletes previously stored objects. Hence, the net fees that a user pays equals gas fees minus the rebates associated with data deletion:
```
net_gas_fees = computation_gas_fee + storage_gas_fee - storage_rebate
```

The information on net gas fees is displayed in a [Sui network explorer](https://suiscan.xyz/mainnet/home) for each transaction block:

![Gas Fees displayed on a Sui network explorer](images/gas-fees-explorer.png "The Gas Fees section displayed on a Sui network explorer")

## Computation gas prices {#computation-prices}

The computation gas price $ComputationPrice[\tau]$ captures the cost of one unit of computation in SUI units. This price is set at the transaction level and submitted by the user as the transaction's gas price. Conceptually, it is useful to think about this gas price in two parts:

$$
ComputationPrice[\tau] = ReferencePrice + Tip[\tau]
$$

On the Sui network, a single $ReferencePrice$ exists throughout each epoch, with Sui validators updating the $ReferencePrice$ at each epoch boundary. Hence, in practice, when a user submits a gas price above the $ReferencePrice$, think of the difference as a tip paid to the network in order to get higher priority. During moments of regular network operations, users are not expected to pay tips and the vast majority of transactions have gas prices equal to $ReferencePrice$.

The Sui gas price mechanism makes the $ReferencePrice$ a credible anchor for you to reference when submitting transactions to the network, providing reasonable confidence that transactions submitted with gas prices at or close to the reference price are executed in a timely manner. This is achieved through three core steps.

### Gas price survey

All validators are surveyed at the start of each epoch, and every validator submits their reservation price. That is, each validator states the minimum gas price at which they are willing to process transactions. The protocol orders these quotes and chooses the 2/3 percentile by stake as the reference price. The gas price survey goal is to set a reference price under which a quorum of validators are willing to promptly process transactions.

### Tallying rule

Throughout the epoch, validators obtain signals over the operations of other validators. Each validator uses these signals to build a subjective evaluation over the performance of every other validator. Specifically, each validator constructs a multiplier for the stake rewards of every other validator such that validators who behave well receive boosted rewards, and validators who do not receive reduced rewards. The tallying rule goal is to create a community-enforced mechanism for encouraging validators to honor the reference gas price.

### Incentivized stake reward distribution rule

At the end of the epoch, the distribution of stake rewards across validators is adjusted using information from the tallying rule. Specifically, a global multiplier is built for every validator using the median value, weighted by stake, out of the set of individual multipliers constructed during the tallying rule. All else equal, validators that operated performantly receive their regular stake rewards, whereas validators who did not operate performantly at the reference gas price receive slashed rewards. Since stake rewards are influenced by the amount of stake each validator owns, validators are encouraged to obtain more stake by lowering gas fees and pricing out inefficient validators. This benefits Sui end users since the stake reward distribution rule incentivizes validators to deliver a more cost-efficient network.

## Storage gas prices {#storage-prices}

The storage gas price $StoragePrice$ captures the costs of covering one unit of storage in perpetuity in SUI units. This price is set through governance proposals and is updated infrequently. The goal is to ensure Sui users pay for their use of on-chain data storage by depositing these fees into the storage fund and then redistributing these fees to future validators. In contrast to the computation gas price, storage prices are fixed and common for all transactions both within an epoch and across epochs until the storage price is updated.

The $StoragePrice$ is set exogenously through the governance proposal with the goal of targeting the off-chain dollar cost of data storage. In the long run, as the costs of storage fall due to technological improvements and the dollar price of the SUI token evolves, governance proposals update the price in order to reflect the new dollar target price.

### Gas prices as a coordination mechanism {#coordination-mechanism}

When you submit transactions with computation gas prices at or close to the current epoch $ReferencePrice$ and storage gas prices at the targeted $StoragePrice$, you have the best user experience. The Sui gas price mechanism provides you with credible reference prices for submitting your transactions. By incentivizing validators to elicit their true reservation prices and honor these quotes, you can credibly assume your transactions are processed in a timely manner.

After Sui enables horizontal scaling, validators can add more workers as demand for on-chain activity scales. This increases their costs linearly at the same pace of network activity and lets them process more transactions at the same low gas prices. In cases of extreme network congestion where validators cannot scale fast enough, the tip presence provides a market-based congestion pricing mechanism that discourages further demand spikes by increasing the cost of transacting on the Sui platform.

In the long run, the Sui gas price mechanism creates incentives for validators to optimize their hardware and operations. Validators that invest in becoming more efficient are able to honor lower gas prices and obtain a stake reward boost. Sui validators are thus encouraged to innovate and improve the experience of end users.

## Gas budgets {#gas-budgets}

You must submit all transactions together with a gas budget. This provides a cap to the amount of gas fees you pay, especially because sometimes it might be hard to perfectly forecast how much a transaction costs before you submit it to the Sui network.

The gas budget for a Sui transaction is defined in SUI units and transactions are successfully executed if:

`gas_budget >= max{computation_fees, total_gas_fees}`

If the gas budget does not fulfill this condition, then the transaction fails and a portion of the gas budget is charged. In cases where the `gas_budget` is insufficient for covering `computation_fees`, then the entirety of the `gas_budget` is charged. In cases where `gas_budget` is sufficient for covering `computation_fees` but not the `total_gas_fees`, then a portion of the `gas_budget` corresponding to `computation_fees` and the fees associated with mutating the transaction's input objects are charged.

Ultimately, a successful transaction requires the end user to pay the transaction's `total_gas_fees`. However, since it is challenging to perfectly forecast computation time before the transaction is processed, the `gas_budget` condition also requires the `gas_budget` to be at least as large as the transaction's `computation_fees` in case the transaction aborts. In some cases, especially in the presence of high storage rebates, and thus negative net storage fees, the gas budget might be higher than the total gas fees you pay.

The minimum gas budget is 2,000 MIST (0.000002 SUI). This ensures validators are compensated with at least 2,000 MIST even if the gas budget is incorrectly specified and the transaction aborts. Additionally, this protects the Sui network from being spammed with a large number of transactions with minimal gas budgets. The maximum gas budget is 50 billion MIST or 50 SUI. This protects the network against overflow of internal multiplications and gas limits for denial of service attacks.

As mentioned previously, the storage rebate currently equals 99% of the originally paid storage fees. Because the gas budget applies to the totality of gas fees, it is often the case that a transaction only goes through if the gas budget is considerably higher than the net gas fees that a user ultimately pays.

### Gas budget examples {#gas-budget-examples}

The following table provides some examples of gas accounting on the Sui network. Within the first two and last two rows, computation units are the same because transactions fall within the same bucket. However, the last two transactions are more complex than the first two and thus fall in a higher bucket. In the last transaction, the storage rebate is large enough to fully offset the transaction gas fees and actually pays the user back a positive amount of SUI.

These examples showcase the importance of the gas budget. The minimum gas budget is the smallest amount a transaction can specify to successfully execute. When there is a storage rebate, the minimum gas budget is larger than the amount of net gas fees a user ultimately pays. This is especially stark in the last example where the user receives a positive amount back for executing the transaction. This is because the minimum gas budget must be higher than a transaction's computation fees.

|                                                         | Reference gas price | Computation units | Storage price | Storage units | Storage rebate | Minimum gas budget | Net gas fees   |
| ------------------------------------------------------- | ------------------- | ----------------- | ------------- | ------------- | -------------- | ------------------ | -------------- |
| Simple transaction storing 10 bytes                     | 1,000 MIST          | 1,000             | 75 MIST       | 1,000         | 0 MIST         | 1,075,000 MIST     | 1,075,000 MIST |
| Simple transaction storing 10 bytes and deleting data   | 500 MIST            | 1,000             | 75 MIST       | 1,000         | 100,000 MIST   | 500,000 MIST       | 475,000 MIST   |
| Complex transaction storing 120 bytes                   | 1,000 MIST          | 5,000             | 200 MIST      | 12,000        | 0 MIST         | 7,400,000 MIST     | 7,400,000 MIST |
| Complex transaction storing 120 bytes and deleting data | 500 MIST            | 5,000             | 200 MIST      | 12,000        | 5,000,000 MIST | 2,500,000 MIST     | -100,000 MIST  |